Supporting the DSL Spectrum

A language tailored to the problem domain can focus on its idioms and jargon, avoiding clumsy, overly general constructs needed to support general-purpose language. The leverage provided by DSLs over conventional programming languages is often extreme; application engineers may specify as little as 2% of the code that one would need to program the same thing in a conventional programming language! But commitment to a DSL approach can be rather expensive. It is often difficult to know when to invest in exactly how much infrastructure support for a product or product family. All of the concerns that are germane to generalpurpose programming language design and support may become important in the support of a specific DSL. At the same time, there is a wide spectrum of approaches to providing DSL support. This paper relates the various DSL design approaches to alternatives for tool support, providing a kind of “DSL tool support selection framework,” indicating where one might expect to need to invest heavily to obtain adequate support and illustrating the spectrum of tradeoffs and situations in which each is appropriate

Abstract Syntax from Concrete Syntax

Modern Software Engineering practice advocates the development of domain-specific specification languages to characterize formally the idioms of discourse and jargon of specific problem domains. With poorly-understood domains it is best to construct an abstract syntax to characterize the domain concepts and abstractions before developing a concrete syntax. Often, however, a good concrete syntax exists a priori: sometimes in sophisticated formal languages characterizing (often mathematical) domains but more often in miniature, legacy-code languages, sorely in need of reverse engineering. In such cases, it is necessary to derive an appropriate abstract syntax – or its first cousin, an object-oriented model – from the concrete syntax. This report describes a transformation process that produces a good abstract representation from a low-level concrete syntax specification

Support for Managing Design-Time Decisions

The desirability of maintaining multiple stakeholders' interests during the software design process argues for leaving choices undecided as long as possible. Yet, any form of underspecification, either missing information or undecided choices, must be resolved before automated analysis tools can be used. This paper demonstrates how Constraint Satisfaction Problem Solution Techniques (CSTs) can be used to automatically reduce the space of choices for ambiguities by incorporating the local effects of constraints, ultimately with more global consequences. As constraints typical of those encountered during the software design process, we use UML consistency and well-formedness rules. It is somewhat surprising that CSTs are suitable for the software modeling domain since the constraints may relate many ambiguities during their evaluation, encountering a well-known problem with CSTs called the k-consistency problem. This paper demonstrates that our CST-based approach is computationally scalable and effective---as evidenced by empirical experiments based on dozens of industrial models

An Externalized Infrastructure for Self-Healing Systems

Software architecture descriptions can play a wide variety of roles in the software lifecycle, from requirements specification, to logical design, to implementation architectures. In addition, execution architectures can be used both to constrain and enhance the functionality of running systems, e.g. security architectures and debugging architectures. Along with others from DARPA's DASADA program we proposed an execution infrastructure for so-called self-healing, self-adaptive systems -- systems that maintain a particular level of healthiness or quality of service (QoS). This externalized infrastructure does not entail any modification of the target system -- whose health is to be maintained. It is driven by a reflective model of the target system's operation to determine what aspects can be changed to effect repair. Herein we present that infrastructure along with an example implemented in accord with it

LCC error messages

Computer Science Departmen